home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-dns-server-mib-00.txt
< prev
next >
Wrap
Text File
|
1993-06-16
|
71KB
|
2,183 lines
draft DNS Server MIB June 93
DNS Server MIB Extensions
10-June-1993
DNS Working Group
Rob Austein
Epilogue Technology Corporation
sra@epilogue.com
Jon Saperia
Digital Equipment Corporation
saperia@tay.dec.com
Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
Please check the id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on the nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
This document will be submitted to the Internet Architecture
Board as a Proposed Standard. This document defines and
experimental extension to the SNMP MIB. Upon publication as a
Proposed Standard, a new MIB number will be assigned. This is
a working document only, it should neither be cited nor quoted
Expires December 10, 1993 [Page 1]
draft DNS Server MIB June 93
in a formal document.
This document will expire before 10 December 1993.
Distribution of this document is unlimited.
Please send comments to the authors.
Expires December 10, 1993 [Page 2]
draft DNS Server MIB June 93
1. Introduction
This memo defines a set of extensions that have been created
for the Internet MIB which instrument DNS Server Functions and
was produced by the DNS working group. This memo does not
specify a standard for the Internet community.
With the adoption of The Simple Network Management Protocol
(RFC 1157), the Management Information Base for network
management of TCP/IP-based internets (RFC 1213), and the
Structure of Management Information (RFC 1155) by the
Internet, and a large number of vendor implementations of
these standards in commercially available products, it became
possible to provide a higher level of effective network
management in TCP/IP-based internets than previously
available. With the growth in the use of these standards, it
has become possible to consider the management of other
elements of the infrastructure beyond the basic TCP/IP
protocols. A key element of the TCP/IP infrastructure is the
DNS.
Up to this point there has been no mechanism to integrate the
management of the DNS with SNMP-based managers. This memo
provides the mechanisms by which IP-based management stations
can effectively manage DNS server software in an integrated
fashion through the use of the standard Internet SMI, MIB and
Simple Network Management Protocol.
New DNS MIB objects have been defined to be used in
conjunction with the Internet MIB to allow access and control
of the DNS server software via SNMP by the Internet community.
Expires December 10, 1993 [Page 3]
draft DNS Server MIB June 93
2. The Network Management Framework
The Internet-standard Network Management Framework consists of
four components. They are:
o RFC 1155 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management. RFC 1212 defines a more concise description
mechanism, which is wholly consistent with the SMI.
o RFC 1213 defines MIB-II, the core set of managed objects
for the Internet suite of protocols.
o RFC 1157 which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the
purpose of experimentation and evaluation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) defined in the SMI. In particular, each object
object type is named by an OBJECT IDENTIFIER, an
administratively assigned name. The object type together with
an object instance serves to uniquely identify a specific
instantiation of the object. For human convenience, we often
use a textual string, termed the descriptor, to refer to the
object type.
2.2. Format of Definitions
Section 5 contains the specification of all object types
contained in this MIB module. The object types are defined
using the conventions defined in the SMI, as amended by the
extensions specified in [5,6].
Expires December 10, 1993 [Page 4]
draft DNS Server MIB June 93
3. Overview
In theory, the DNS world is pretty simple. There are two
kinds of entities: resolvers and name servers. Resolvers ask
questions. Name servers answer them. The real world,
however, is not so simple. Implementors have made widely
differing choices about how to divide DNS functions between
resolvers and servers. They have also constructed various
sorts of exotic hybrids. The most difficult task in defining
this MIB was to accommodate this wide range of entities
without having to come up with a separate MIB for each.
We divided up the various DNS functions into two, non-
overlapping classes, called 'resolver functions' and 'name
server functions'. A DNS entity that performs what we define
as resolver functions contains a resolver, and therefore must
implement the MIB groups required of all resolvers which are
defined in a separate MIB Module. A DNS entity which
implements name server functions is considered to be a name
server, and must implement the MIB groups required for name
servers in this Module. If the same piece of software
performs both resolver and server functions, we imagine that
it contains both a resolver and a server and would thus
implement both the DNS Server and DNS Resolver MIBs.
In our model, a resolver is a program (or piece thereof) which
obtains resource records from servers. Normally it does so at
the behest of an application, but may also do so as part of
its own operation. A resolver sends DNS protocol queries and
receives DNS protocol replies. A resolver neither receives
queries nor sends replies. A full service resolver is one
that knows how to resolve queries: it obtains the needed
resource records by contacting a server authoritative for the
records desired. A stub resolver does not know how to resolve
queries: it sends all queries to a local name server, setting
the recursion desired flag to indicate that it hopes that the
name server will be willing resolve the query. A resolver may
(optionally) have a cache for remembering previously acquired
resource records. It may also have a negative cache for
remembering names or data that have been determined not to
exist.
A name server is a program (or piece thereof) that provides
resource records to resolvers. All references in this
document to 'a name server' imply 'the name server's role'.
Expires December 10, 1993 [Page 5]
draft DNS Server MIB June 93
(In some cases the name server's role and the resolver's role
might be combined into a single program.) A name server
receives DNS protocol queries and sends DNS protocol replies.
A name server neither sends queries nor receives replies. As a
consequence, name servers do not have caches. Normally, a
name server would expect to receive only those queries to
which it could respond with authoritative information.
However, if a name server receives a query that it cannot
respond to with purely authoritative information, it may
choose to try to obtain the necessary additional information
from a resolver which may or may not be a separate process.
Expires December 10, 1993 [Page 6]
draft DNS Server MIB June 93
4. Selected Objects
Many of the objects included in this memo have been created
from information contained in the DNS specification. The DNS
specification is found in Domain Names - Concepts and
Facilities (RFC 1034) and Domain Names - Implementation and
Specification (RFC 1035), as amended and clarified by
Requirements for Internet Hosts - Application and Support
(RFC1123). Additional usage information is found in the
Domain Administrators Guide (RFC 1032), and the Domain
Administrators Operations Guide (RFC 1033). Other objects
have been created based on experience with existing DNS
management tools, expected operational need, and the
statistics generated by existing DNS implementations. These
objects have been ordered into groups as follows:
Server Configuration Group
Server Counter Group
Server Special Counter Group
Records Group
Server Management Group
Some of the objects defined in this memo have been created
from information contained in existing configuration files
used by many DNS implementations. This information has been
converted into a standard form using the Internet Standard SMI
defined in RFC 1155. The object descriptors used in this MIB
have been created from a variety of sources. For the most
part, the descriptions are influenced by by the DNS related
RFCs noted above. For example, the descriptors for counters
used for the various types of queries of DNS records are
influenced by the definitions used for the various record
types found in Domain Names - Implementation and Specification
RFC 1035.
Expires December 10, 1993 [Page 7]
draft DNS Server MIB June 93
5. Textual Conventions
Several data types have been introduced as a textual
conventions in this DNS MIB document. These additions will
facilitate the common understanding of information used by the
DNS. No changes to the SMI or the SNMP are necessary to
support these conventions which are described in the
Definitions section. Enumerated integers are not used for
many of the textual conventions defined in this document
because the DNS is defined such that additional data types can
be added without the server being recoded. The use of
standard integer definitions for many of these data types
allows this mib to accomodate these changes as well.
Expires December 10, 1993 [Page 8]
draft DNS Server MIB June 93
6. Definitions
RFCxxxx-dnsServMIB
DEFINITIONS ::= BEGIN
IMPORTS
IpAddress, Counter,
experimental
FROM RFC1155-SMI
DisplayString
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- DNS MIB
dns OBJECT IDENTIFIER ::= { experimental 43 }
dnsServ OBJECT IDENTIFIER ::= { dns 1 }
-- textual conventions
DnsDate ::= OCTET STRING (SIZE (8 | 11))
-- This data type is intended to provide a consistent
-- method of reporting date information. The information
-- is organized as follows: the first two octets represent
-- the year, the next two are for the month and day of the
-- year. The next three octets are for hours, minutes and
-- seconds. The next octet is for deci-seconds. Direction
-- from UT is in the next octet. The next two octets are for
-- hours and minutes from UT. Note that in systems which do not
-- track UT, they will return only the first 8 octets. The table
-- below is intended to help to make clear this convention.
--
-- field octets contents range
-- 1 1-2 year 0..65536
-- 2 3 month 1..12
-- 3 4 day 1..31
-- 4 5 hour 0..23
-- 5 6 minutes 0..59
-- 6 7 seconds 0..60
-- (use 60 for leap-second)
-- 7 8 deci-seconds 0..9
-- 8 9 direction from UT "+" / "-"
-- 9 10 hours from UT 0..11
Expires December 10, 1993 [Page 9]
draft DNS Server MIB June 93
-- 10 11 minutes from UT 0..59
-- For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would
-- be displayed as on a management station:
-- 1992-5-26,13:30:15.0,-4:0
DnsName ::= OCTET STRING
-- A DNS name is a sequence of labels. When DNS names are displayed,
-- the boundaries between labels are typically indicated by dots (e.g.
-- "Acme" and "COM" are labels in the name "Acme.COM" ). In the DNS
-- protocol, however, no such separators are needed because each label
-- is encoded as a length octet followed by the indicated number of
-- octets of label. For example, "Acme.COM" is encoded as the octet
-- sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O', 'M', 0 } (the final
-- 0 is the length of the name of the root domain, which appears
-- implicitly at the end of any DNS name). This MIB uses the same
-- encoding as the DNS protocol.
-- A DnsName must always be a fully qualified name. It is an error to
-- encode a relative domain name as a DnsName without first making it a
-- fully qualified name.
DnsClass ::= INTEGER (0..65535)
-- This data type is used to represent the class values which appear
-- in Resource Records in the DNS. A 16-bit unsigned integer is
-- used to allow room for new classes of records to be defined.
-- Existing standard classes are listed in the DNS specification.
DnsType ::= INTEGER (0..65535)
-- This data type is used to represent the type values which appear
-- in Resource Records in the DNS. A 16-bit unsigned integer is
-- used to allow room for new record types to be defined.
-- Existing standard types are listed in the DNS specification.
DnsQClass ::= INTEGER (0..65535)
-- This data type is used to represent the QClass values which appear
-- in Resource Records in the DNS. A 16-bit unsigned integer is
-- used to allow room for new QClass records to be defined. Existing
-- standard QClasses are listed in the DNS specification.
DnsQType ::= INTEGER (0..65535)
-- This data type is used to represent the QType values which appear
-- in Resource Records in the DNS. A 16-bit unsigned integer is
-- used to allow room for new QType records to be defined.
-- Existing standard QTypes are listed in DNS specification.
Expires December 10, 1993 [Page 10]
draft DNS Server MIB June 93
DnsTime ::= INTEGER
-- DnsTime values are 32-bit unsigned integers which measure time in
-- seconds.
DnsValid ::= INTEGER { valid (1), clear (2) }
-- Many of the tables in this MIB have as one of their columns, an
-- object which can be set to a value of 2 to delete that
-- row of the table. If a read operation is performed on this
-- object, a value of 1 is returned to indicate a valid row in the
-- table.
DnsOpCode ::= INTEGER (0..15)
-- This data type is used to represent the DNS OPCODE used in the
-- header section of DNS messages. Existing standard OPCODE values
-- are listed in the DNS specification.
DnsRespCode ::= INTEGER (0..15)
-- This data type is used to represent the DNS RCODE value in response
-- messages. Existing standard RCODE values are listed in the DNS
-- specification.
-- groups in the dns server mib
dnsServConfig OBJECT IDENTIFIER ::= { dnsServ 1 }
dnsServCounter OBJECT IDENTIFIER ::= { dnsServ 2 }
dnsServSpecCounter OBJECT IDENTIFIER ::= { dnsServ 3 }
dnsServRec OBJECT IDENTIFIER ::= { dnsServ 4 }
dnsServMgmt OBJECT IDENTIFIER ::= { dnsServ 5 }
-- Server Configuration Group
-- The implementation of the Server Configuration Group is
-- mandatory for all systems which implement DNS server software
-- functions.
dnsServConfigImplementIdent OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The implementation identification string for the DNS
server software in use on the system, for example;
FNS2.1"
::= { dnsServConfig 1 }
Expires December 10, 1993 [Page 11]
draft DNS Server MIB June 93
dnsServConfigRecurs OBJECT-TYPE
SYNTAX INTEGER {
available (1),
restricted (2),
unavailable (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This represents the recursion status of requests made
to this server. The possible values are: available -
performs recursion on requests from clients.
Restricted - recursion is performed on requests only
from certain clients, for example; clients on an access
control list. Unavailable - recursion is not available."
::= { dnsServConfig 2 }
-- Server Counter Group
-- The implementation of the Server Counter Group is mandatory for
-- all systems which offer either recursive or non recursive server
-- software functions.
dnsServCounterUTime OBJECT-TYPE
SYNTAX DnsTime
ACCESS read-only
STATUS mandatory
DESCRIPTION
"If the server has a persistent state, e.g., a
process; this value will be the time elapsed since it
started. For software that does not have persistence,
this value will be 0."
::= { dnsServCounter 1 }
dnsServCounterAuthAns OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries which were authoritatively answered."
::= { dnsServCounter 2 }
dnsServCounterAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
Expires December 10, 1993 [Page 12]
draft DNS Server MIB June 93
STATUS mandatory
DESCRIPTION
"Number of queries for which authoritative no such
name responses were made."
::= { dnsServCounter 3 }
dnsServCounterAuthNoDataResps OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries for which authoritative no such data
(empty answer) responses were made."
::= { dnsServCounter 4 }
dnsServCounterNonAuthDatas OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries which were non-authoritatively answered
(cached data)."
::= { dnsServCounter 5 }
dnsServCounterNonAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries for which there has been a
non-authoritative no such name answer given."
::= { dnsServCounter 6 }
dnsServCounterNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries which were non-authoritatively answered
with no data (empty answer)."
::= { dnsServCounter 7 }
dnsServCounterRefs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
Expires December 10, 1993 [Page 13]
draft DNS Server MIB June 93
STATUS mandatory
DESCRIPTION
"Number of requests that were referred to other servers."
::= { dnsServCounter 8 }
dnsServCounterErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed that were
answered with errors (RCODE values other than 0 and 3).
RCODE values are defined in RFC1035."
::= { dnsServCounter 9 }
dnsServCounterRelNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests received by the server for names that
are only 1 label long (text form - no internal dots)."
::= { dnsServCounter 10 }
dnsServCounterReqRefs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of DNS requests refused by the server process."
::= { dnsServCounter 11 }
dnsServCounterReqUnparses OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests received which were unparseable."
::= { dnsServCounter 12 }
dnsServCounterOtherErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
Expires December 10, 1993 [Page 14]
draft DNS Server MIB June 93
"Number of requests which were aborted for other
(local) server errors."
::= { dnsServCounter 13 }
-- DNS Server Counter Table
dnsServCounterTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServCounterEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Counter information based on DNS class and
record type."
::= { dnsServCounter 14 }
dnsServCounterEntry OBJECT-TYPE
SYNTAX DnsServCounterEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains count information for each DNS
record and class type known to the server. The index
allows management software to to create indices to the
table to get the specific information desired, e.g.,
number or A record queries over UDP which came to this
server. In order to prevent an uncontrolled expansion of
rows in the table; if dnsServCounterRequests is 0 and
dnsServCounterResponses is 0, then the row does not exist
and no such is returned when the agent is queried for such
instances."
INDEX { dnsServCounterOpCode, dnsServCounterQClass,
dnsServCounterQType, dnsServCounterTransport }
::= { dnsServCounterTable 1 }
DnsServCounterEntry ::=
SEQUENCE {
dnsServCounterOpCode
DnsOpCode,
dnsServCounterQClass
DnsClass,
dnsServCounterQType
DnsType,
dnsServCounterTransport
INTEGER,
dnsServCounterRequests
Expires December 10, 1993 [Page 15]
draft DNS Server MIB June 93
Counter,
dnsServCounterResponses
Counter
}
dnsServCounterOpCode OBJECT-TYPE
SYNTAX DnsOpCode -- INTEGER (0..15)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The DNS OpCode being counted in this row of the
table."
::= { dnsServCounterEntry 1 }
dnsServCounterQClass OBJECT-TYPE
SYNTAX DnsClass -- INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The class of record being counted in this row
of the table."
::= { dnsServCounterEntry 2 }
dnsServCounterQType OBJECT-TYPE
SYNTAX DnsType -- INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The type of record which is being counted in this row
in the table."
::= { dnsServCounterEntry 3 }
dnsServCounterTransport OBJECT-TYPE
SYNTAX INTEGER {
udp (1),
tcp (2),
other (3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A value of 1 indicates that the queries reported on
this row were sent using UDP. A value of 2 indicates
that TCP was used. 3 is for any transport other than
TCP or UDP."
::= { dnsServCounterEntry 4 }
Expires December 10, 1993 [Page 16]
draft DNS Server MIB June 93
dnsServCounterRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests (queries) that have been recorded
in this row of the table."
::= { dnsServCounterEntry 5 }
dnsServCounterResponses OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of responses made by the server since
initialization for the type of query identified
on this row of the table."
::= { dnsServCounterEntry 6 }
-- Server Special Counter Group
-- The implementation of the Server Special Counter Group is mandatory
-- only for those systems which make distinctions between the different
-- sources of the DNS queries as defined below.
-- Objects in this group are implemented on servers which make the
-- distinction between queries which originate with the local host,
-- within the same zone as the local host, or come from outside the
-- zone of the server. The objects found in the Server Counter group
-- are totals, thus if one wanted to separately identify, for example,
-- the number of queries which have been given Authoritative Answers
-- which originated from 'remote' hosts - subtract the current values of
-- servSpecCounterFriendsAuthAns and servSpecCounterSelfAuthAns
-- from servCounterAuthAns.
-- The purpose of these distinctions is to allow for implementations to
-- group queries and responses on this basis. One way in which servers
-- may make these distinctions is by looking at the source IP address of
-- the DNS query. If the source of the query is 'your own' then the
-- query should be counted as 'yourself' - local host. If the source of
-- the query matches an 'access list' - the the query came from a friend,
-- that is; within the local zone. What constitutes an 'access
-- list' is implementation dependent and could be as simple as all
-- hosts on the same IP network as the DNS server are classed as in
Expires December 10, 1993 [Page 17]
draft DNS Server MIB June 93
-- the local zone and are 'friends'. In order to avoid double
-- counting, the following rules apply:
-- 1. No host is in more than one of the three groups defined above.
-- 2. All queries from the local host are always counted in the
-- 'yourself' group regardless of what the access list, if any,
-- says.
-- 3. The access list should not define 'your friends' in such a way
-- that it includes all hosts, that is 'not everybody is your
-- friend'.
dnsServSpecCounterSelfAuthAns OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative answer."
::= { dnsServSpecCounter 1 }
dnsServSpecCounterSelfAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative no such name answer
given."
::= { dnsServSpecCounter 2 }
dnsServSpecCounterSelfAuthNoDataResps OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative no such data answer
(empty answer) made."
::= { dnsServSpecCounter 3 }
dnsServSpecCounterSelfNonAuthDatas OBJECT-TYPE
SYNTAX Counter
Expires December 10, 1993 [Page 18]
draft DNS Server MIB June 93
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
a non-authoritative answer (cached data) was made."
::= { dnsServSpecCounter 4 }
dnsServSpecCounterSelfNonAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been a non-authoritative no such name answer
given."
::= { dnsServSpecCounter 5 }
dnsServSpecCounterSelfNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
a non-authoritative answer - no such data response was
made (empty answer)."
::= { dnsServSpecCounter 6 }
dnsServSpecCounterSelfRefs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries the server has processed
which originated from a resolver on the same
host and were referred to other servers."
::= { dnsServSpecCounter 7 }
dnsServSpecCounterSelfErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
Expires December 10, 1993 [Page 19]
draft DNS Server MIB June 93
"Number of requests the server has processed which
originated from a resolver on the same host which
have been answered with errors (RCODE values other
than 0 and 3). RCODE values are defined in RFC1035."
::= { dnsServSpecCounter 8 }
dnsServSpecCounterSelfRelNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests received for names that are only
1 label long (text form - no internal dots) the
server has processed which originated from a resolver
on the same host."
::= { dnsServSpecCounter 9 }
dnsServSpecCounterFriendsAuthAns OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries originating from friends which
were authoritatively answered. The definition of
friends is a locally defined matter."
::= { dnsServSpecCounter 10 }
dnsServSpecCounterFriendsAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries originating from friends, for
which authoritative no such name (NXDOMAIN) responses
were made. The definition of friends is a locally
defined matter."
::= { dnsServSpecCounter 11 }
dnsServSpecCounterFriendsAuthNoDataResps OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries originating from friends for
which authoritative no such data (empty answer)
Expires December 10, 1993 [Page 20]
draft DNS Server MIB June 93
responses were made. The definition of friends is
a locally defined matter."
::= { dnsServSpecCounter 12 }
dnsServSpecCounterFriendsNonAuthDatas OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries originating from friends which
were non-authoritatively answered (cached data).
The definition of friends is a locally defined matter."
::= { dnsServSpecCounter 13 }
dnsServSpecCounterFriendsNonAuthNoNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from friends for which there has been a
non-authoritative no such name answer given."
::= { dnsServSpecCounter 14 }
dnsServSpecCounterFriendsNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of queries originating from friends which
were non-authoritatively answered with no such data
(empty answer)."
::= { dnsServSpecCounter 15 }
dnsServSpecCounterFriendsRefs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests which originated from friends
that were referred to other servers. The definition
of friends is a locally defined matter."
::= { dnsServSpecCounter 16 }
dnsServSpecCounterFriendsErrors OBJECT-TYPE
Expires December 10, 1993 [Page 21]
draft DNS Server MIB June 93
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests the server has processed which
originated from friends and were answered with errors
(RCODE values other than 0 and 3). RCODE values are
defined in RFC1035. The definition of friends is a
locally defined matter."
::= { dnsServSpecCounter 17 }
dnsServSpecCounterFriendsRelNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of requests received for names from friends
that are only 1 label long (text form - no internal
dots) the server has processed."
::= { dnsServSpecCounter 18 }
-- Records Group
-- The implementation of the Records Group is mandatory for all
-- systems which implement DNS server software functions.
-- Records Table
-- The records table contains information on the contents of all the
-- authoritative zones loaded by this server.
dnsServRecTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServRecEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information on the contents of all the authoritative zones
loaded by the server."
::= { dnsServRec 1 }
dnsServRecEntry OBJECT-TYPE
SYNTAX DnsServRecEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
Expires December 10, 1993 [Page 22]
draft DNS Server MIB June 93
"Detail information on authoritative zone information and
pending changes."
INDEX { dnsServRecZoneName, dnsServRecZoneClass, dnsServRecName,
dnsServRecType, dnsServRecIndex }
::= { dnsServRecTable 1 }
DnsServRecEntry ::=
SEQUENCE {
dnsServRecZoneName
DnsName,
dnsServRecZoneClass
DnsClass,
dnsServRecName
DnsName,
dnsServRecFullName
DnsName,
dnsServRecType
DnsType,
dnsServRecTTL
DnsTime,
dnsServRecData
OCTET STRING,
dnsServRecIndex
INTEGER,
dnsServRecHits
Counter,
dnsServRecStatus
INTEGER,
dnsServRecValid
DnsValid
}
dnsServRecZoneName OBJECT-TYPE
SYNTAX DnsName -- OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Zone name to which the Resource Record which
is identified in this row of the table belongs.
This is the owner name of the zone's SOA RR, as
described in RFC1034."
::= { dnsServRecEntry 1 }
dnsServRecZoneClass OBJECT-TYPE
SYNTAX DnsClass -- INTEGER (0..65535)
ACCESS read-only
Expires December 10, 1993 [Page 23]
draft DNS Server MIB June 93
STATUS mandatory
DESCRIPTION
"DNS class of the zone contained in this row. For classes
listed in the DNS specification, the values are the same."
::= { dnsServRecEntry 2 }
dnsServRecName OBJECT-TYPE
SYNTAX DnsName -- OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Name of the Resource Record which is identified in
this row of the table. This is the portion of the name
which is the part other than the zone name. As described
in RFC1034, the owner of the record is the domain name
where the RR is found."
::= { dnsServRecEntry 3 }
dnsServRecFullName OBJECT-TYPE
SYNTAX DnsName -- OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the complete name of the entry identified in this
row of the table as it appears in the zone. It preserves
the case sensitivity of the information which is stored in
upper case only in the dnsServRecZoneName and
dnsServRecName objects."
::= { dnsServRecEntry 4 }
dnsServRecType OBJECT-TYPE
SYNTAX DnsType -- INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The type of the record identified in this row of the
table. For types defined in the DNS specification,
the values are the same."
::= { dnsServRecEntry 5 }
dnsServRecTTL OBJECT-TYPE
SYNTAX DnsTime
ACCESS read-only
STATUS mandatory
DESCRIPTION
Expires December 10, 1993 [Page 24]
draft DNS Server MIB June 93
"The larger of the Time-To-Live value for this record
and the Zone Minimum for the zone containing it."
::= { dnsServRecEntry 6 }
dnsServRecData OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Variable length of octets. Type and Class information
provided in this row of the table along with this data
tell the management station how to interpret the Record.
For information on the details of DNS Resource Records
and their formats, see RFC1035."
::= { dnsServRecEntry 7 }
dnsServRecIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A unique index value which identifies each entry in
this table."
::= { dnsServRecEntry 8 }
dnsServRecHits OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Number of hits the server has had on the resource record
defined in this row of the table. A hit on a RR is counted
whenever it is included in a response."
::= { dnsServRecEntry 9 }
dnsServRecStatus OBJECT-TYPE
SYNTAX INTEGER {
inUse (1),
pendingModification (2),
pendingDeletion (3),
pendingAddition (4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
Expires December 10, 1993 [Page 25]
draft DNS Server MIB June 93
"The status of the information represented in this row of
the table.
IN USE - a value of 1 indicates that the information
represented by this row of the table is currently in use
the by server. That is, this information is the current
authoritative information read in by the server at startup.
PENDING MODIFICATION - A value of 2 indicates that this row
of the table represents a change to existing data already
in use by the server. Each entry in the table which has a
value of 2 will always have a pair entry with a value of 1.
This modification will take effect when the
dnsServMgmtReload object is next set to a value of 2 or 3.
PENDING DELETION - A value of 3 indicates that the
information represented by this row of the table will be
deleted from the authoritative zone information when the
dnsServMgmtReload object is next set to a value of 2 or 3.
PENDING ADDITION - A value of 4 indicates that this is new
authoritative data for the zone which in not yet in use.
This new information will be added to the authoritative
information for the zone when the dnsServMgmtReload object
is next set to a value of 2 or 3."
::= { dnsServRecEntry 10 }
dnsServRecValid OBJECT-TYPE
SYNTAX DnsValid
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Set to CLEAR to delete this entry from this table."
::= { dnsServRecEntry 11 }
-- Server Management Group
-- The implementation of the Server Management Group is mandatory
-- for all systems which implement DNS server software functions.
dnsServMgmtReload OBJECT-TYPE
SYNTAX INTEGER {
restart (1),
load (2),
loadAndStart (3),
Expires December 10, 1993 [Page 26]
draft DNS Server MIB June 93
other (4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"When set to the values above, the following actions
are taken:
RESTART - The name server process is restarted and
existing configuration files are read in.
LOAD - Changes which have been made to information in
the DNS Management Zone Configuration and Server Record
Tables are loaded into the permanent database of the
server. After the load operation is completed, all
entries in the Management Zone Configuration and Server
Record Modification Tables are removed which had
dnsServRecStatus or dnsServMgmtZoneStatus values of 2,
3 or 4.
LOAD AND START - Changes which have been made to
information in the DNS Management Zone Configuration
and Server Record Tables are loaded into the permanent
database of the server. After the load operation is
completed, all entries in the Management Zone
Configuration and Server Record Modification Tables are
removed which had dnsServRecStatus or
dnsServMgmtZoneStatus values of 2, 3 or 4. After this
load is completed the name server process is restarted.
OTHER - is returned when a read operation is performed
on this object.
If an entry has the same index as an existing entry in the
server database, then the entry in the permanent database
is changed to be equal to the new values."
::= { dnsServMgmt 1 }
-- DNS Management Zone Configuration Table
-- This table contains zone configuration information. Information is
-- changed for the server when the value of dnsServMgmt 1 is set to 2 or
-- 3.
Expires December 10, 1993 [Page 27]
draft DNS Server MIB June 93
dnsServMgmtZoneTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServMgmtZoneEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of zones for which this name server is
configured. If name server doesn't load any zones,
this table is empty."
::= { dnsServMgmt 2 }
dnsServMgmtZoneEntry OBJECT-TYPE
SYNTAX DnsServMgmtZoneEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the name server zone table."
INDEX { dnsServMgmtZoneName,
dnsServMgmtZoneClass }
::= { dnsServMgmtZoneTable 1 }
DnsServMgmtZoneEntry ::=
SEQUENCE {
dnsServMgmtZoneName
DnsName,
dnsServMgmtZoneLoad
OCTET STRING,
dnsServMgmtZoneDate
DnsDate,
dnsServMgmtZoneClass
DnsClass,
dnsServMgmtZoneLastReload
DnsTime,
dnsServMgmtZoneLastReloadAttempt
DnsTime,
dnsServMgmtZoneLastSource
IpAddress,
dnsServMgmtZoneStatus
INTEGER,
dnsServMgmtZoneValid
DnsValid
}
dnsServMgmtZoneName OBJECT-TYPE
SYNTAX DnsName
ACCESS read-write
STATUS mandatory
Expires December 10, 1993 [Page 28]
draft DNS Server MIB June 93
DESCRIPTION
"DNS name of the zone to which this row of the table
applies. This is the SOA RR. See RFC 1035 for details of
the SOA RDATA format."
::= { dnsServMgmtZoneEntry 1 }
dnsServMgmtZoneLoad OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The name of the zone file read to load the data
for this zone when the zone was last loaded or updated.
A value of NULL indicates that the data was not loaded
from a named file (e.g., because it was down-loaded from
another server using the DNS protocol's zone transfer
facility)."
::= { dnsServMgmtZoneEntry 2 }
dnsServMgmtZoneDate OBJECT-TYPE
SYNTAX DnsDate -- DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the date that the information found in
dnsServMgmtZoneLoad was last changed at the time
the zone was last loaded. A value of NULL indicates
that there is no dnsServMgmtZoneLoad file."
::= { dnsServMgmtZoneEntry 3 }
dnsServMgmtZoneClass OBJECT-TYPE
SYNTAX DnsClass -- INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"DNS class of the RRs in this zone."
::= { dnsServMgmtZoneEntry 4 }
dnsServMgmtZoneLastReload OBJECT-TYPE
SYNTAX DnsTime
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Elapsed seconds since last successful reload of
this zone."
Expires December 10, 1993 [Page 29]
draft DNS Server MIB June 93
::= { dnsServMgmtZoneEntry 5 }
dnsServMgmtZoneLastReloadAttempt OBJECT-TYPE
SYNTAX DnsTime
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Elapsed seconds since last attempted reload of
this zone."
::= { dnsServMgmtZoneEntry 6 }
dnsServMgmtZoneLastSource OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"IP address of host from which most recent reload of
this zone was received. If unknown or irrelevant,
value should be 0.0.0.0."
::= { dnsServMgmtZoneEntry 7 }
dnsServMgmtZoneStatus OBJECT-TYPE
SYNTAX INTEGER {
inUse (1),
pendingModification (2),
pendingDeletion (3),
pendingAddition (4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The status of the information represented in this row of
the table.
IN USE - a value of 1 indicates that the information
represented by this row of the table is currently in use
the by server. That is, this information is the current
zone configuration information.
PENDING MODIFICATION - A value of 2 indicates that this row
of the table represents a change to existing data already
in use by the server. Each entry in the table which has a
value of 2 will always have a pair entry with a value of 1.
This modification will take effect when the
dnsServMgmtReload object is next set to a value of 2 or 3.
Expires December 10, 1993 [Page 30]
draft DNS Server MIB June 93
PENDING DELETION - A value of 3 indicates that the
information represented by this row of the table will be
deleted from the zone configuration file(s) when the
dnsServMgmtReload object is next set to a value of 2 or 3.
PENDING ADDITION - A value of 4 indicates that this is new
zone file configuration data which is not yet in use. This
new information will be added to the zone configuration
file(s) when the dnsServMgmtReload object is next set to a
value of 2 or 3."
::= { dnsServMgmtZoneEntry 8 }
dnsServMgmtZoneValid OBJECT-TYPE
SYNTAX DnsValid
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Set to CLEAR to delete this zone entry from this table."
::= { dnsServMgmtZoneEntry 9 }
-- DNS Management Server Table
dnsServMgmtServTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServMgmtServEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table is a list of IP addresses from which it will
attempt to load zone information using DNS zone transfer
operations."
::= { dnsServMgmt 3 }
dnsServMgmtServEntry OBJECT-TYPE
SYNTAX DnsServMgmtServEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the name server server (sic) table."
INDEX { dnsServMgmtServName,
dnsServMgmtServClass,
dnsServMgmtServAddr }
::= { dnsServMgmtServTable 1 }
DnsServMgmtServEntry ::=
SEQUENCE {
Expires December 10, 1993 [Page 31]
draft DNS Server MIB June 93
dnsServMgmtServName
DnsName,
dnsServMgmtServClass
DnsClass,
dnsServMgmtServAddr
IpAddress
}
dnsServMgmtServName OBJECT-TYPE
SYNTAX DnsName
ACCESS read-only
STATUS mandatory
DESCRIPTION
"DNS name of the zone to which this entry applies."
::= { dnsServMgmtServEntry 1 }
dnsServMgmtServClass OBJECT-TYPE
SYNTAX DnsClass -- INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"DNS class of zone to which this entry applies."
::= { dnsServMgmtServEntry 2 }
dnsServMgmtServAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"IP address of name server host from which this zone
might be obtainable."
::= { dnsServMgmtServEntry 3 }
END
Expires December 10, 1993 [Page 32]
draft DNS Server MIB June 93
7. Acknowledgements
This document is the result of work undertaken the by DNS
working group. In addition, the contributions and comments of
the following members are also specially acknowledged:
Philip Almquist, Computer Communication consultant
Joe Peck, Digital Equipment Corporation
Frank Kastenholz, FTP Software
Win Treese, Digital Equipment Corporation
Mimi Zohar, IBM
Expires December 10, 1993 [Page 33]
draft DNS Server MIB June 93
8. References
J. Reynolds and J. Postel, Assigned Numbers. Internet
Working Group Request for Comments 1010. Network
Information Center, SRI International, Menlo Park,
California, (May, 1987).
M. Stahl, Domain Administrators Guide. Internet Working
Group Request for Comments 1032. Network Information
Center, SRI International, Menlo Park, California,
(November, 1987).
M. Lottor, Domain Administrators Operations Guide,
Internet Working Group Request for Comments 1033. Network
Information Center, SRI International, Menlo Park,
California, (November, 1987).
P. Mockapetris, Domain Names - Concepts and Facilities,
Internet Working Group Request for Comments 1034. Network
Information Center, SRI International, Menlo Park,
California, (November, 1987).
P. Mockapetris, Domain Names - Implementation and
Specification, Internet Working Group Request for
Comments 1035. Network Information Center, SRI
International, Menlo Park, California, (November, 1987).
V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
R. Braden (editor) Requirements for Internet Hosts --
Application and Support, Internet Working Group Request
for Comments 1123. Network Information Center, SRI
International,Menlo Park, California, (October, 1989).
M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1155. Network
Information Center, SRI International, Menlo Park,
California, (May, 1990).
K. McCloghrie and M.T. Rose, Management Information Base
Expires December 10, 1993 [Page 34]
draft DNS Server MIB June 93
for Network Management of TCP/IP-based internets,
Internet Working Group Request for Comments 1156, Network
Information Center, SRI International, Menlo Park,
California, (May, 1990).
J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1157. Network Information
Center, SRI International, Menlo Park, California, (May,
1990).
M.T. Rose, The Open Book, A Practical Perspective on OSI.
Prentice Hall, Englewood Cliffs, New Jersey, (1990).
M.T. Rose and K. McCloghrie (editors) Concise MIB
Definitions, Internet Working Group Request for Comments
1212, Network Information Center, SRI International,
Menlo Park, California, (March, 1991).
K. McCloghrie and M.T. Rose (editors), Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II, Internet Working Group Request for
Comments 1213. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
Expires December 10, 1993 [Page 35]
draft DNS Server MIB June 93
9. Security Considerations
Security issues are not discussed in this memo.
10. Author's Addresses
Rob Austein
Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 01864
USA
Voice: +1 617 942 0915
Email: sra@epilogue.com
Jon Saperia
Digital Equipment Corporation
153 Taylor Street
M/S TAY2-2/B5
Littleton, MA 01460
Voice: +1 508-952-3171
Email: saperia@tay.dec.com
Expires December 10, 1993 [Page 36]
draft DNS Server MIB June 93
Table of Contents
1 Introduction .......................................... 3
2 The Network Management Framework ...................... 4
2.1 Object Definitions .................................. 4
2.2 Format of Definitions ............................... 4
3 Overview .............................................. 5
4 Selected Objects ...................................... 7
5 Textual Conventions ................................... 8
6 Definitions ........................................... 9
7 Acknowledgements ...................................... 33
8 References ............................................ 34
9 Security Considerations ............................... 36
10 Author's Addresses ................................... 36
Expires December 10, 1993 [Page 37]